The name of the package class currently has to follow a convention. This classname is based on the java package of the OTObject that it if for. Currently packages are mainly used for registering controllers. The reason for this approach is:

• java does not provide a standard way to find all the classes in a package, so you cannot just search for a OT*Package file inside of the package.
• using the same name for class in different packages is confusing for developer when they have to work with more than one.
  This is why all OT*Package classes are not called OTPackage.

If you are having problems getting your package recognized you can use the following system property:

-Dotrunk.trace.packages=true

if this is true OTrunk will print the name of each OT*Package it looks for.

If for example the className is com.example.datagraph.state.OTDataCollector
It looks for a class called: com.example.datagraph.state.OTDatagraphPackage

This is figured out by

1. Taking off the classname
   com.example.datagraph.state
2. striping off the .state (if there is one)
   com.example.datagraph
3. If the packages starts with "org.concord" then it is handle specially, otherwise:
4. taking the last element of the package name
   datagraph
5. capitalizing the first leter and adding OT to the front and package to back
   OTDatagraphPackage
6. use the original package of the imported class
   com.example.datagraph.state.OTDatagraphPackage

If the package starts with "org.concord" then there is special handling for more nested java packages.

For example: org.concord.graph.util.state.OTPoint2D

1. Steps 1 and 2 above are followed.
2. org.concord is stripped off
   graph.util
3. each dot separated string is capitalized.
   GraphUtil
4. OT is added to the front and Package to the back
   OTGraphUtilPackage
5. the original package of pre-pended:
   org.concord.graph.util.state.OTGraphUtilPackage
   Then org.concord

Future Notes

This approach for finding packages is not ideal. In the future, packages will be imported in otml files instead of classes. And each package will list its OTClasses. So the need for this approach will go away.